Network Working Group H. Alvestrand 
Request for Comments: 1494 SINTEF DELAB 
S. Thompson 

Soft*Switch, Inc. 

August 1993 


Equivalences between 1988 X.400 and RFC-822 Message Bodies 
Status of this Memo 
This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 


Distribution of this memo is unlimited. 


Table of Contents 


Lo .Iutrfodücbrcorn: Sode ana a 4390 mvodd wq Venu eue eue qv 2 
2. Equivalence Table Definition ..................... eese 2 
3. Generic Conversions: 2.2243 eae x) ex | xr e Tp UR RUE Daas S 3 
3S.l. Byte COPY dqees.Seteue e RUE ep Se RR eels had eee SEA in e eer ede 3 
3.2 Text. CODnVerSTOLliumae^nrivugeawecni hrs E E steam a a eres T 3 
83534. Image ConvefSiOn.zsveveegse xis EUR E PIER SUE E USUS E Rie UR Rete 3 
3.4 TURNS LANG) ls Se. Soe qu acetates e I Euro UR PvE EUR R NON S SUR eee eee UR. m 3 
4. Conversion Table for known X.400 and MIME Types ......... 4 
kakta- MIME CO- X400 L3bXe.-z-ce X Rec RU RES RE CU RS 4 
4.22:.:X 400. Eo-MIME Table 225.5549... lnc ote ee Be colt a She 4 
5. Newly defined X.400 Body Parts ................ eee 5 
Dishes Use of OBJECT IDENTIFIERS and ASN.1 MACROS ............. 5 
5.2. The Generic MIME Extended Body Part .................... 6 
55:34. .-LhesBostScrrzpt body partt s. Gy a dow E EE 7 
Su. Ehe JPEG: body (PARE shee wens ea aa ev eue teLe iR eus ene e iae E er Ne ibus 7 
545v Che-GIE' body Daft xe iets eeu ace RU UR E egal eae Boe See E e 8 
6. Newly defined MIME content-types ............... ccce 8 
6.1. The application/x400-bp content-type ............... ee 8 
6,2. The- mage/g3tax content type sourie t ec se els exei 9 
6.25.1 .P»G3kax«Pdrameters o li: Tuiu i eer xe ERES EE 9 
62222. "Gontenbt^kneodgsng 235955 ROLE Lu SMS Sas e SEES SS 10 
6.3. The Application/ODA content-type ............ celere 11 
Tu Equivabtence Definitions 2 9)$-)2 £n $e Cae ed oes avr es lt 
Tatan TASTE = text/plain c.scl1— wake eR ERR ET ERES IT 
7.25; GeneralText = text/plain (180-8859) i.i... ro: 12 
7.3. BilaterallyDefined - application/octet-stream .......... 13 
As ODA = application/oda-... vs ea RUE ER RUNE NU UN AER RRUNUA S 14 
TDs 9G3=facsimi le. = imageAg3fax wv. sve VEU. LENSES dU. e. 15 
7.6. application/postscript - postscript-body-part .......... 16 
qToT.capplrcation/jpeg.--3peg-cbody-part seseris eea oe I. elg 16 


Alvestrand & Thompson [Page 1] 


RFC 1494 X.400/MIME Body Equivalences August 1993 


Tees image/gif. —uJIf-DOody-part:!ziinla see hh eee eet 16 

8; OID.Asstjnmenus 4 Wiens de Recess tiet adie a Sed beh E ware ert in iE De EE E 17 

9. IANA Registration form for new mappings ................... cT 

T0'.—Security-Conszderations- 4. we wA ESAME. 18 

IT. Authors. Addresses Zoe meer mU evocare Rte erem ee Rino ras 18 

l2: References cars die a shave yet aie have eran ib ws hae Sy aan eae ae wie s vue sessi e 19 
1. Introduction 


This document is a companion to [1], which defines the principles 
behind interworking between MIME-based RFC-822 mail and X.400 mail. 
This document describes the content of the "IANA MHS/MIME Equivalence 
table" referenced in the companion document, and defines the initial 
configuration of this table. Mappings for new MIME content-types 
and/or X.400 body part types should be registered with the IANA to 


minimize redundancy and promote interoperability. 


In MIME, the term "content-type" is used to refer to an information 
object contained in the body of a message. In contrast, X.400 uses 
the term "body part type." In this document, the term "body part" is 
used to refer to either. 


Please send comments to the MIME-MHS mailing list: 
<mime-mhs@surfnet.nl>. 


2. Equivalence Table Definition 


For each MIME content-type/X.400 body part pair, the Equivalence 
Table will contain an entry with the following sections: 


X.400 Body Part 
This section identifies the X.400 Body Part governed by this 
Table entry. It includes any OBJECT IDENTIFIERs or other 
parameters necessary to uniquely identify the Body Part. 


MIME Content-Type 
This section identifies the MIME content-type governed by this 
Table entry. The MIME content-type named here must be 
registered with the IANA. 


Conversion Type 
This section identifies the type of conversion applied. See the 
section on Generic Conversions for an explanation of the 
possible values. 
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Comments (optional) 
This section gives any additional commentary that might be 
useful in understanding the mapping between the X.400 and MIME 
representations. 


The initial Equivalence Table entries in this document are described 
using this convention. Any future submissions to the IANA should 
follow this format. 


3. Generic conversions 


3.1. Byte copy 


This is the trivial case, that is, no conversion at all. The byte 


= 


stream is simply copied between MIME and X.400. 


This is the preferred conversion, since it is the simplest. 


Implementors and vendors will be registering OBJECT IDENTIFIERs and 
MIME content-types for their various objects. They are STRONGLY 
ENCOURAGED to specify their content formats such that a gateway can 
use Byte Copy to map between them. 


Note that in some cases, it is necessary to define exactly which 
ASN.1 construct to replace with the content of the MIME object. 


3.2. Text Conversion 


This type of conversion applies to text objects that cannot be mapped 
using a simple Byte Copy. Conversion involves scanning and 
reformatting the object. For example, the MIME and X.400 objects 
might differ in their encoding of nonstandard characters, or line or 
page breaks. 


3.3. Image Conversion 


This conversion type applies to raster images, like Group 3 Facsimile 
or JPEG. Again, it differs from Byte Copy in that it involves 
scanning reformatting the byte stream. It differs from Text 
Conversion in that it is pixel- oriented, rather than character- 
oriented. 


3.4.  Tunneling 


This is not a conversion at all, but an encapsulation of the object. 
This is the fallback conversion, used when no explicit mapping 
applies. 


Alvestrand & Thompson [Page 3] 


RFC 1494 X.400/MIME Body Equivalences August 1993 


4. Conversion Table for known X.400 and MIME Types 


This section itemizes the equivalences for all currently known MIME 
content-types and X.400 body parts. 


4.1. MIME to X.400 Table 


MIME content-type X.400 Body Part Section 
text/plain 

charset-us-ascii ia5-text es 

charset-iso-8859-x EBP - GeneralText T2 
text/richtext no mapping defined 522 
application/oda EBP - ODA 7.4 
application/octet-stream bilaterally-defined ane 
application/postscript EBP - mime-postscript-body 5.4, 7.6 
image/g3fax g3-facsimile 6:2, T5 
image/jpeg EBP - mime-jpeg-body Dub, Te T 
image/gif EBP - mime-gif-body 5.6, 7.8 
audio/basic no mapping defined 522 
video/mpeg no mapping defined 5.2 


Abbreviation: EBP - Extended Body Part 
4.2. X.400 to MIME Table 


Basic Body Parts 


X.400 Basic Body Part MIME content-type Section 
ia5-text text/plain;charset=us-ascii 7.1 

voice No Mapping Defined 6.1 
g3-facsimile image/g3fax 6.2, 7.5 
g4-classl no mapping defined 6.1 
teletex no mapping defined 6.1 
videotex no mapping defined 6.1 
encrypted no mapping defined 6.1 
bilaterally-defined application/octet-stream HS 
nationally-defined no mapping defined 6.1 
externally-defined See Extended Body Parts 6. T. 

X.400 Extended Body Part  MIME content-type Section 
GeneralText text/plain;charset-iso-8859-x 7.2 

ODA application/oda qua 
mime-postscript-body application/postscript 5d s. 
mime-jpeg-body image/jpeg 5.24, 7. 
mime-gif-body image/gif bby K8 
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5. Newly defined X.400 Body Parts 


This section defines new X.400 Body Parts for the purposes of 
interworking with MIME. 


All new X.400 Body Parts defined here will be Extended Body Parts, as 
defined in CCITT Recommendation X.420 [2]. 


5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS 


X.420 dictates that Extended Body Parts shall: 


(1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify 
the contents, and 


(2) be defined by using the ASN.1 Macro: 


EXTENDED-BODY-PART-TYPE MACRO: := 
BEGIN 


TYPE NOTATION Parameters Data 


VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 
Parameters ::— "PARAMETERS" type "IDENTIFIED" 
"BY" value(OBJECT IDENTIFIER) 
| empty; 
Data ::— "DATA" type 
END 


To meet these requirements, this document uses the OID 
mime-mhs-bodies 


defined in [1], as the root OID for X.400 Extended Body Parts defined 
for MIME interworking. 


Each Extended Body Part contains Data and optional Parameters, each 
being named by an OID. To this end, two OID subtrees are defined 
under mime-mhs-bodies, one for Data, and the other for Parameters: 


mime-mhs-bp-data OBJECT IDENTIFIER ::= 
{ mime-mhs-bodies 1 } 
mime-mhs-bp-parameter OBJECT IDENTIFIER ::- 
{ mime-mhs-bodies 2 } 


All definitions of X.400 body parts submitted to the IANA for 
registration must use the Extended Body Part Type macro for the 
definition. See the next section for an example. 
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Lastly, the IANA will use the mime-mhs-bp-data and mime-mhs-bp- 
parameter OIDs as root OIDs for any new MIME content-type/subtypes 
that aren't otherwise registered in the Equivalence Table. 


5.2. The Generic MIME Extended Body Part 


The following X.400 Body Part is defined to carry any MIME content- 
type for which there is no explicit IANA registered mapping. 


mime-body-part EXTENDED-BODY-PART-TYPE 
PARAMETERS MimeParameters 
IDENTIFIED BY mime-generic-parameters 
DATA OCTET STRING 
::= mime-generic-data 


MimeParameters ::- 
SEQUENCE { 
content-type IA5String, 
content-parameters SEQUENCE OF 
SEQUENCE { 
parameter IA5String, 
parameter-value TA5String 


} 


-- from RFC-1327, sec. 5.1.12 
other-header-fields RFC822FieldList 
} 


mime-generic-parameters OBJECT IDENTIFIER 
( mime-mhs-bp-parameter 1 } 

mime-generic-data OBJECT IDENTIFIER 
{ mime-mhs-bp-data 1 } 


To convert the MIME content-type into the X.400 mime- body-part: 


(1) Copy the "type/subtype" string from the MIME 
Content-Type: header field into 
MimeParameters.content-type 


(2) For each "parameter-value" string in the MIME 
Content-Type header field, create a 
MimeParameters.content-parameters structure, and copy 
the "parameter" string into MimeParameters.content- 
parameters.parameter field and the "value" string 
into the paired MimeParameters.content- 
parameters.parameter-value field. 


(3 Convert the MIME body part into its canonical form. 
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(See appendix H of RFC 1341 [3] for a discussion 

of canonical in this context.) Said another way, 
reverse the transfer encoding to recover the original 
byte stream. 


(4) Copy the canonical byte stream into the mime-body- 
part.data octet string. 


(5) Remove the Content-type and the Content-transfer- 
encoding header fields from the MIME body part's 
RFC822 header. 


(6) Any header fields starting with "Content-" in the 
MIME body part is placed in the optional other- 
header-fields structure. Note that this can only 
occur when the MIME content-type occurs as part of a 
"multipart" content-type. 


The mapping from the X.400 mime-body-part to a MIME content-type 
the inverse of the above steps. 


5.3. The PostScript body part 


The following Extended Body Part is defined for PostScript data 
streams. It has no parameters. 


postscript-body-part EXTENDED-BODY-PART-TYPE 


DATA OCTET STRING 
:= mime-postscript-body 


mime-postscript-body OBJECT IDENTIFIER ::= 
{ mime-mhs-bp-data 2 } 


5.4. The JPEG body part 


1993 


is 


The following Extended Body Part is defined for JPEG data streams. 


It has no parameters. 


jpeg-body-part EXTENDED-BODY-PART-TYPE 
DATA OCTET STRING 
::= mime-jpeg-body 


mime-jpeg-body OBJECT IDENTIFIER ::- 
{ mime-mhs-bp-data 3 } 
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5.5. The GIF body part 


The following Extended Body Part is defined for GIF data streams. It 
has no parameters. 


gif-body-part EXTENDED-BODY-PART-TYPE 
DATA OCTET STRING 
:- mime-gif-body 


mime-gif-body OBJECT IDENTIFIER ::- 
{ mime-mhs-bp-data 4 } 


6. Newly defined MIME content-types 


This section defines new MIME content-types for the purposes of 
interworking with X.400. 


6.1. The application/x400-bp content-type 


This content-type is defined to carry any X.400(88) body part for 
which there is no registered IANA mapping. 


The content-type field is 
application/x400-bp 
The parameters are: 


bp-type-«INTEGER or OBJECT IDENTIFIER» 


The body contains the raw ASN.1 IPM.body octet stream, including the 
initial tag octet. 


If the body is a basic body part, the bp-type parameter is set to the 
number of the body part's context-specific tag, that is, the tag of 
the IPMS.Body.BodyPart component. 


If the body is an Extended Body Part, the bp-type parameter is set to 
the OBJECT IDENTIFIER from 


IPMS.body.externally-defined.data.direct-reference 
No attempt is made to turn the parameters of Extended Body Parts into 
MIME parameters. (This task is the responsibility of the recipient's 


UA). 


For example, a basic VideotexBodyPart will have 
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Content-type-application/x400-bp; bp-type-6 
whilst a Extended Videotex body part will have 
Content-type-application/x400-bp; bp-type-2.6.1.4.5 


application/x400-bp will need a content-transfer-encoding of base64 
or quoted-printable when carried in 7-bit MIME. Since there is no 
way to know beforehand the content, it is recommended to just inspect 
the first 1 KByte or so of data and choose the one that seems to 
produce the more compact encoding. 


If this is not feasible, Base64 is recommended. 

6.2. The image/g3fax content-type 
This content-type is defined to carry G3 Facsimile byte streams. 
In general, a G3Fax image contains 3 pieces of information: 


(1) A set of flags indicating the particular coding 
Scheme. CCITT Recommendation T.30 defines how the 
flags are transmitted over telephones. In this 
medium, the flags are carried as parameters in the 
MIME content-type header field. 


(2) A structure that divides the bits into pages.  CCITT 
recommendation T.30 describes how to define page 
boundaries. A page break algorithm is defined here 
that is independent of how the image data is 


conveyed. 

(3 For each page, a sequence of bits that form the 
encoding of the image. CCITT recommendation T.4 
defines the bit image format. This is used without 
change. 

6.2.1.  G3Fax Parameters 


The following parameters are defined: 
(1) page-length - possible values: A4, B4 and Unlimited 
(2) page-width - possible values: A3, A4, B4 


(3) encoding - possible values: 1-dimensional, 2- 
dimensional, Uncompressed 
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(4) resolution - possible values: Fine, Coarse 
(5) DCS - a bit string, represented in Base64. 


(6) pages - an integer, giving the number of pages in the 
document 


If nothing is specified, the default parameter settings are: 


page-length=A4 
page-width=A4 
encoding-1-dimensional 
resolution-Coarse 


It is possible (but misleading) to view the representation of these 
values as single-bit flags. They correspond to the following bits of 
the T.30 control string and X.400 G3FacsimileParameters: 


Parameter T.30 bit X.400 bit 
page-length-A4 no bit set 
page-length=B4 19 21 
page-length-Unlimited 20 20 
page-width=A4 no bit set 
page-width=A3 18 22 
page-width-B4 17 23 
encoding-1-dimensional no bit set 
encoding-2-dimensional 16 8 
encoding-Uncompressed 26 30 
resolution-Coarse no bit set 
resolution-Fine 15 9 


The reason for the different bit numbers is that X.400 counts bits in 
an octet from the MSB down to the LSB, while T.30 uses the opposite 
numbering scheme. 


If any bit but these are set in the Device Control String, the DCS 
parameter should be supplied. 


6.2.2. Content Encoding 


X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT 
STRINGs. Each BIT STRING is a page of facsimile image data, encoded 
as defined by Recommendation T.4. The following content encoding is 
reversible between MIME and X.400 and ensures that page breaks are 
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honored in the MIME representation. 
An EOL is defined as a bit sequence of 

000000000001 (eleven zeroes and a one). 
Each page of the message is delimited by a sequence of six (6) EOLs 
that MUST start on a byte boundary. The image bit stream is padded 
as needed to achieve this alignment. 
Searching for the boundary is a matter of searching for the byte 


sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside 
the image. 


See Section 7.5 for the algorithm on conversion between this encoding 
and the X.400 encoding. 


The Base64 content-transfer-encoding is appropriate for carrying this 
content-type. 


6.3. The Application/ODA content-type 
The "ODA" subtype of application is used to indicate that a body 
contains information encoded according to the Office Document 
Architecture [4] standards, using the ODIF representation format. 
For application/oda, the Content- Type line should also specify an 
attribute/value pair that indicates the document application profile 
(DAP), using the key word "profile", and the document class, using 
the keyword "class". 


For the keyword "class", the values "formatted", "processable" and 
"formatted-processable" are legal values. 


Thus an appropriate header field might look like this: 


Content-Type:  application/oda; profile-0112; 
class-formatted 


Consult the ODA standard [4] for further information. 

The Base64 content-transfer-encoding is appropriate for carrying ODA. 
7.  Equivalence Definitions 
7.1.  IA5Text - text/plain 


X.400 Body Part: IA5Text 
MIME Content-type: text/plain; charset-US-ASCII 
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Conversion Type: Byte copy 
Comments: 


When mapping from X.400 to MIME, the "repertoire" parameter is 
ignored. 


When mapping from MIME to X.400, the "repertoire" parameter is set to 
IA5 (5). 


NOTE: The MIME Content-type headers are omitted, when mapping from 
X.400 to MIME, if and only if the IA5Text body part is the only body 
part in the IPMS.Body sequence. 


NOTE: IA5Text specifies the "currency" symbol in position 2/4. This 
is converted without comment to the "dollar" symbol, since the author 
of this document has seen many documents in which the position was 
intended to indicate "dollar" while he has not yet seen one in which 
the "currency" symbol is intended. 


(For reference: The T.50 (1988) recommendation, which defines IA5, 
talks about ISO registered set number 2, while ASCII, using the 
"dollar" symbol, is ISO registered set number 6. There are no other 
differences.) 


7.2. GeneralText - text/plain (ISO-8859) 


X.400 Body Part: GeneralText; CharacterSets in 
6,100,101,109,110,126,127,138,144,148 

MIME Content-Type: text/plain; charset-ISO-8859- (1-9) 

Conversion Type: Byte copy 

Comments: 


When mapping from X.400 to MIME, the character-set chosen from table 
below according to the value of Parameters.CharacterSets. 


When mapping from MIME to X.400, GeneralText is an Extended Body 
Part, hence it requires an OID. The OID for the GeneralText body is 
defined in [5], part 8, annex D, as {2 6 1 4 11}. The OID for the 
parameters is (206 1 11 11). 


The Parameters.CharacterSets is set from table below according to the 
value of "charset" 


NOTE: The GeneralText body part is defined in ISO 10021-8 [5], and 
NOT in the corresponding CCITT recommendation. Its parameters were 
heavily modified in a defect report, and will be a SET OF INTEGER 

(indicating the ISO registry numbers of all the used sets) in the 

next version of the standard. 
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The following table lists the MIME character sets and the 
corresponding ISO registry numbers. If no correspondence is found, 
this conversion fails, and the generic body part approach is used. 


MIME charset ISO IR numbers Comment 

ISO-8859-1 6, 100 West European "8-bit ASCII" 
TSO-8859-2 6, 101 East European 

TSO-8859-3 6, 109 <regarded as obsolete> 
IS0-8859-4 6, 110 «regarded as obsolete» 
TSO-8859-5 6, 144 Cyrillic 

ISO-8859-6 6, 127 Arabic 

ISO-8859-7 6, 126 Greek 

ISO-8859-8 6, 138 Hebrew 

TSO-8859-8 6, 148 Other Latin-using languages 


When converting from MIME to X.400, generate the correct OIDs for use 
in the message envelope’s Encoded Information Types by looking up the 
ISO IR number in the above table, and then appending it to the id- 
cs-eit-authority {1 0 10021 7 1 0} OID. 


The escape sequences to designate and invoke the relevant character 
sets in their proper positions must be added to the front of the 
GeneralText character string. 


7.3. BilaterallyDefined - application/octet-stream 


X.400 Body Part: BilaterallyDefined 

MIME Content-Type: Application/Octet-Stream (no parameters) 
Conversion Type: Byte copy 

Comments: 


When mapping from MIME to X.400, if there are parameters present in 
the Content-Type: header field, the conversion fails since the 
BilaterallyDefined Body Part does not have any corresponding ASN.1 
parameters. 


DISCUSSION: The parameters "name" "type" and "conversions" are 
advisory, but may in some cases give vital hints on the expected 
handling of the file. The parameter "conversions" is not fully 
defined, but it is expected that it will be useful, so we cannot drop 
it and expect people to be satisfied. 


The parameter "padding" changes the interpretation of the last byte 
of the data, and so cannot be deleted. 


An option is to prepend an IA5 body part that contains the parameter 
text; this will aid unmodified readers, and can probably be made 
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reversible with suitable chicanery, but is it worth it???? 


Also, use of BilaterallyDefined Body Parts is specifically deprecated 
in both 1988 and 1992 X.400. It is retained solely for backward 
compatibility with 1984 systems. 1992 X.400 defines a File Transfer 
Body Part to solve this problem (i.e. binary file transfer through 
email). The standard and its regional profiles are not solid enough 
yet to exploit as a solution for this problem. 


7.4. ODA - application/oda 


X.400 Body Part: ODA 

MIME Content-Type: application/oda 
Conversion Type: Byte copy 
Comments: 


The ODA body part is defined in the CCITT document T.411 [6], 
appendix E, section E.2, "ODA identification in the P2 protocol of 


MHS" 
An abbreviated version of its ASN.1 definition is: 


oda-body-part EXTENDED-BODY-PART-TYPE 


PARAMETERS OdaBodyPartParameters 
DATA OdaData 
::— id-et-oda 

OdaBodyPartParameters ::- SET { 
document-application-profile [0] OBJECT IDENTIFIER 
document-architecture-class [1] INTEGER { 


formatted (0) 
processable (1) 
formatted-processable (2) }} 


id-et-oda OBJECT IDENTIFIER ::= { 2 8101 } 


Mapping from X.400 to MIME, the following is done: 


The Parameters.document-application-profile is mapped onto the MIME 
parameter "profile" according to the table below. 


Profile OBJECT IDENTIFIER 


Q112 { iso (1) identified-organization (3) ewos (16) 
eg (2) oda (6) profile (0) q112 (1) } 


The Parameters.document-architecture-class is mapped onto the MIME 
parameter "class" according to the table below 
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String Integer 

formatted formatted (0) 

processable processable (1) 
formatted-processable formatted-processable (2) 


NOTE: This parameter is not defined in RFC 1341. 


The body of the MIME content-type is the Data part of the ODA body 
part. 


When mapping from MIME to X.400, the following steps are done: 


The Parameters.document-application-profile and Parameters.document- 


architecture-class are set from the tables above. If any of the 
parameters are missing, the values for Q112 and formatted-processable 
are used. 


It is an option for the gateway implementor to try to access them 
from inside the document, where they are defined as 


document-profile.document-characteristics.document-architecture-class 
document-profile.document-characteristics.document-application-profile 
Gateways are NOT required to do this, since the document- 
characteristics are optional parameters. If a gateway does not, it 
simply uses the defaulting rules defined above. 

The OBJECT IDENTIFIERs for the document application profile and for 


ODA (28 0 0) must be added to the Encoded Information Types 
parameter of the message envelope. 


7.5. g3-facsimile - image/g3fax 


X.400 Body part: g3-facsimile 
MIME Content-Type: image/g3fax 
Conversion Type: nearly Byte copy 
Comments: 


The Parameters of the X.400 G3Fax body part are mapped to the 
corresponding Parameters on the MIME Image/G3Fax body part and vice 


versa. Note that: 


(1) If fineResolution is not specified, pixels will be 
twice as tall as they are wide 


(2) If any bit not corresponding to a specially named 
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option is set in the G3Fax NonBasicParameters, the 
"DCS" parameter must be used. 


(3) Interworking is not guaranteed if any bit apart from 
those specially named are used in the 
NonBasicParameters 


From X.400 to G3Fax, the body is created in the following way: 


(1) Any trailing EOL markers on each bitstring is 
removed. The bistring is padded to a byte boundary. 


(2) 6 consecutive EOL markers are appended to each 
bitstring. 


(3 The padded bitstrings are concatenated together 


1993 


An EOL marker is the bit sequence 000000000001 (11 zeroes and a one). 


From G3Fax to X.400, the body is created in the following way: 
(1) The body is split into bitstrings at each occurrence 
of 6 consecutive EOL markers, and trailing EOLs and 
padding are removed 


(2) Each bitstring is made into an ASN.1 BITSTRING 


(3) The bitstrings are made into an ASN.1 SEQUENCE, which 
forms the body of the G3Fax body part. 


7.6. application/postscript - postscript-body-part 
X.400 Body Part: Extended Body Part, OID postscript-body-part 
MIME Content-Type: application/postscript 
Conversion Type: Byte Copy 
7.7.  application/jpeg - jpeg-body-part 
X.400 Body Part: Extended Body Part, OID jpeg-body-part 


MIME Content-Type: application/jpeg 
Conversion Type: Byte Copy 


7.8. image/gif - gif-body-part 


X.400 Body Part: Extended Body Part, OID gif-body-part 
MIME Content-Type: application/gif 
Conversion Type: Byte Copy 
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8. OID Assignments 
MIME-MHS-MAPPINGS DEFINITIONS ::= BEGIN 
IMPORTS 
mail, mime-mhs, mime-mhs-bodies 


FROM MIME-MHS; 


mime-mhs-bp-data OBJECT IDENTIFIER ::- 
{ mime-mhs-bodies 1} 


mime-mhs-bp-parameter OBJECT IDENTIFIER ::= 
{ mime-mhs-bodies 2} 


mime-generic-data OBJECT IDENTIFIER ::= 
{ mime-mhs-bp-data 1} 


mime-generic-parameters OBJECT IDENTIFIER ::= 
( mime-mhs-bp-parameter 1) 


mime-postscript-body OBJECT IDENTIFIER ::= 
( mime-mhs-bp-data 2] 


mime-jpeg-body OBJECT IDENTIFIER ::- 
{ mime-mhs-bp-data 3} 


mime-gif-body OBJECT IDENTIFIER ::= 
( mime-mhs-bp-data 4); 


9. IANA Registration form for new mappings 


To: IANAGisi.edu 
Subject: Registration of new X.400/MIME content type mapping 


MIME type name: 

(this must have been registered previously with IANA) 
X.400 body part: 

X.400 Object Identifier for Data: 


(If left empty, an OID will be assigned by IANA under 
mime-mhs-bp-data) 


X.400 Object Identifier for Parameters: 
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(If left empty, an OID will be assigned by IANA under 
mime-mhs-bp-parameter. If it is not used, fill in the 
words NOT USED.) 

X.400 ASN.1 Syntax: 


(must be an EXTENDED-BODY-PART-TYPE macro, or reference to 
a Basic body part type) 


Conversion algorithm: 


(must be defined completely enough for independent 
implementation. It may be defined by reference to RFCs). 


Person & email address to contact for further information: 
INFORMATION TO THE SUBMITTER: 
The accepted registrations will be listed in the "Assigned 
Numbers" series of RFCs. The information in the 
registration form is freely distributable. 
10. Security Considerations 
Security issues are not discussed in this memo. 
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